Factory reset GNSS_MODEL_MTK GPS modules with PCAS10,3 #3388
Conversation
titan098
force-pushed
the
mtk_gps_factory_reset_with_pcas10_3
branch
from
b2d9bd7 to
a8e3c37
Compare
|
@GPSFan I'd like your perspective on this as well |
|
I'm curious as to how gpsd was able to configure an AT6558 to send ubx protocol. I can't find anything in the CASIC spec or the datasheet for the AT6558 that says it supports ubx. |
|
It's not really u-blox ubx protocol, it shares a similar format and has many of the same Class & ID identifiers. Similar to the AllyStar Tau1202. The Message header is different, B5 62 for u-blox, BA CE for the AT6558, and F1 D9 for AllyStar. The more recent u-blox receivers have depracated most of the ubx protocol commands in favor of the VALSET/VALGET/VALDEL command structure as found on the M10 modules. |
There was a problem hiding this comment.
The command is correct for the CASIC protocol.
However, the L76K is not an MTK device, the L76B is an MTK device and uses $PMTKxxx commands.
For a Factory reset, one would use the $PMTK104 message: PMTK_CMD_FULL_COLD_START. Meshtastic currently does not have any code to support the L76B, so until there is a desire to support the L76B this PR is fine the way it is. I haven't had time to do an audit of the complete init process for other than u-blox parts, it's on the list...
|
Thanks for the insight, this resulted from my particular edge case (using custom dev builds and spare hardware). So if this is something that is not generally beneficial to folk and could be addressed with broader changes later on please feel free to close this. As it stands this only really has minor benefit for me and everything does work as is without issue :) |
|
Meshtastic has a lot of use cases and the off the wall DIY projects can lead to new commercial or semi commercial products, so supporting a variety of GPS modules is eventually a benefit to all. |
|
@GPSFan L76B support is on my todo list for today, as part of a new pico board support. |
|
@caveman99 I don't have an L76B to test with, DayJob & RealLife bogging down progress ;>( |
* (1/3) Support L76B GNSS chip found on pico waveshare shield. Original work by @Mictronics * NodeInfo broadcast ensure default on 0 and enforce 1 hour minimum (meshtastic#3415) * NodeInfo broadcasts ensure defaults on 0 and enforce 1 hour minumum * Doh! * Hey that's not on config! * We don't use Lorawan (meshtastic#3417) #warning "Persistent storage not supported!" [-Wcpp] * [create-pull-request] automated change (meshtastic#3418) Co-authored-by: thebentern <[email protected]> * fix compilation * don't fix this to a hardware model. * new Accelerometer lib (meshtastic#3413) * new Accelerometer lib * Use our fork till upstreasm merges changes. * that PR escalated quickly * resurrect display flip * that should work now * (2/3) Add Slow Clock Support for RP2040 platform. This will disable USB Softserial. * More comprehensive client proxy queue guards (meshtastic#3414) * More comprehensive MQTT thread and queue guards * Consolidate logic * Remove channel check * Check for map_reporting_enabled as well * Update message * Remove channel check from here as well * One liner * Start the mqtt thread back up when channels change and we want mqtt * fix for I2C scan getting stuck (meshtastic#3375) * refactor: add delay for T-Echo peripherals setup * comment out `PIN_POWER_EN1` * [create-pull-request] automated change (meshtastic#3419) Co-authored-by: thebentern <[email protected]> * Handle for heartbeat toradio packets (meshtastic#3420) * Factory reset GNSS_MODEL_MTK GPS modules with PCAS10,3 (meshtastic#3388) Co-authored-by: Ben Meadors <[email protected]> * [create-pull-request] automated change (meshtastic#3422) Co-authored-by: thebentern <[email protected]> * (3/3) Add variant for pico with waveshare and GPS hat (meshtastic#3412) * (3/3) Add variant for pico with waveshare and GPS hat, utilizing slow clock. * Not everybody has Serial2 * Trunk * Push it real gud * No init --------- Co-authored-by: Ben Meadors <[email protected]> --------- Co-authored-by: Thomas Göttgens <[email protected]> Co-authored-by: Ben Meadors <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: thebentern <[email protected]> Co-authored-by: Andre K <[email protected]> Co-authored-by: David Ellefsen <[email protected]>
Problem
Some low-cost GPS modules may not respond to the Ublox factory reset command when a factory reset is requested (those identified as
GNSS_MODEL_MTK). It can be useful to perform a factory reset of the module in particular if it has been used before to ensure the module will just emit the expected NMEA0183 sentences.Proposal
For a device that identifies as
GNSS_MODEL_MTKperform a factory reset with$PCAS10,3*1Fwhen requested.Example
AT6558-5N-31gps module that identifies asGNSS_MODEL_MTKas the device responds to$PCAS06,0*1B\r\nUBXmessages (which this one supports).RMCandGGAmessages: https://github.com/meshtastic/firmware/blob/master/src/gps/GPS.cpp#L288Testing
gpsdand then connected to a microcontroller running Meshtastic.References